Computer applications are becoming increasingly prevalent in society. Pencil and paper, mechanical systems, and others have been replaced by electronics that are controlled by computer programs. These computer applications now handle financial information, automobile assembly processes, power systems, and many other types of functionality, systems, and processes.
At a basic level, computer applications include processes (e.g., approval of a financial transaction, steering of a robotic arm in an automobile assembly line) and data (e.g., how much is a transaction, who will approve a transaction, coordinates and/or velocity for how a robotic arm moves). With such applications both the processes that operate and the data that is being operated on are of value and should be protected.
As the prevalence of computer applications has grown, the need for techniques to secure such applications also has grown. Security can be broken down into two sub-disciples, namely, authentication and authorization.
Authentication may be performed to verify that the person (or process) is who it says it is. For example, a person that logs into a website authenticates that that person is that user. This is a fairly straightforward form of authentication, as it may be possible that the person logging in is not, in fact, the person “associated” with that account. Accordingly, more stringent forms of authentication may be employed (e.g., such as 2-factor authentication) in order to increase the reliability that the person is who he/she says he/she is.
A second aspect of security is called authorization, which may be used to grant access to resources (e.g., processes, data, etc.). One element of authorization that relates to how such access is granted is known as a security context. Security contexts can include information related to the user, assigned roles, permission data that may be provided when the user authenticates, etc. These contexts can then be used to determine whether the user (or other entity) associated with the context is authorized to interact with a given piece of data (or process).
Given that determining what users (and their associated contexts) can access may be application-specific for the resources involved, in certain instances it may not be possible to provide an abstract authorization scheme (e.g., a framework). A newly developed application may include application-specific logic regarding how/what users or objects can access or view the processes and data of the application. For example, in a cluster of applications in a cloud computing scenario, the applications that are sharing data may not have knowledge of other algorithms, processes, etc., that facilitate authorization of the use (or view) of such data.
Some existing frameworks work with authentication and authorization, for example:
1) Spring Security (formerly Acegi): The Spring framework provides first class collaboration with other parts of the Spring framework, a dependency injection pattern, and aspect oriented programming facilities. Both authentication and authorization capabilities on top of them are provided. Both are declarative (with XML) and stored in LDAP, RDBMS, or XML files. Authorization uses Access Control Lists (ACL). The ACLs are stored within client databases in a preconfigured schema that are installed on behalf of the customer. Authorization is implemented by annotating a method or calling the authorization API inside a method directly. The security context is provided through a static method and stored inside a thread local variable for distinction. This behavior sets a prerequisite that one request is always processed with one thread. The synchronization sink is the database, which means every application could read these ACLs and doing authorization.
2) JEE security: JEE includes the Java Authentication and Authorization Service (JAAS) based credentials that are managed by a central container. The credentials include users and roles and are used for authorization through programmatic or annotation techniques. An authorization property file is provided which holds entries written in a domain specific language (DSL) that describes granting rules of assets with a predefined permission set. The rules are applied declaratively and executed automatically through the provided security manager inside the containers.
3) Apache Shiro: This framework provides authorization on a permission level. Users can describe permissions, store the permissions as properties of the user, apply them on assets, and check whether access could be granted by matching the user defined permissions with the permissions defined on the assets.
These traditional solutions try to solve the authentication and authorization problems for simple and perhaps the most common requirements in a single application.
However, the above (and other) techniques may have one or more disadvantages in providing application security:
1) In certain instances, XML configuration and static ACL tables in an RDBMS maybe somewhat less flexible and may not be extensible. The permissions may be more static or fixed and not as flexible to define. Even though a user may configure the checking policies of an authorization flow, extension of the authorization flow may be impossible.
2) In certain instances, the credentials may include principals (users) and roles. This role-based approach may be too restrictive on the authorization process and may not support some common use cases. Further, the property file may be static and not able to be extended by other component at runtime to provide extensible authorization extensions.
3) In certain instances, the permission may be static checks that only define whether the permission matches or does not. Further, there may be no extensible, interpreted rules that may be contributed from other components/applications/systems.
Thus, it will be appreciated that there is a need in the art for improved techniques of providing security to applications in, for example, a business or technical process environment in which multiple processes and/or applications communicate with one another. Certain example embodiments may provide functionality for registering extensions to authorization checks and/or may provide distributed authorization checks for security in a non-application specific way and in conjunction with application-specific security.
In certain example embodiments, an authorization system is provided that allows for flexibility of how authorization for a given resource takes place. In certain example embodiments, the authorization system provides extension points that allow abstraction with respect to the component that implements the authorization rules for an implemented component. Accordingly, certain example embodiments may be unobtrusive and may provide for implementation of the authorization component on the component that extends a given extension point.
Certain example embodiments may delegate authorization requests to extending components in order to fulfill such authorization request. This may include forwarding the current security context to the extending component. Certain example embodiments may register responsible components in a registry (or other similar implementation) to provide a way to find and/or delegate authorization requests. Certain example embodiments may provide hooks for extensibility, which may be used by the extending component so that application-specific (e.g., localized) process or data authorization requests may be realized.
In certain example embodiments, a computer implemented method is provided for distributed authorization. The method is provided on a processing system that includes at least one processor and a memory for executing plural software applications. A security context is created for a client of a first application. In the first application, a connection is accepted from a client of the first application. The client is authenticated and a request from the client to access at least one resource in the first application is accepted. The first application communicates with the second application to determine whether the authenticated client is authorized to access the at least one resource. In the second application, an authorization process is executed on the processing system based on the communication from the first application and the security context. For at least one step in the authorization process, the second application communicates with another application to determine whether the client is authorized to access the at least one resource. Based on this determination, the first application allows or does not allow access.
In certain example embodiments, an authorization system for granting access to a resource of a computing application is provided. The system includes a storage medium that is configured to store a three part permission structure that is associated with the resource. The three part permission structure includes: (1) a first part that includes a domain or type of the resource; (2) a second part that defines at least one action that is done on the resource; and (3) a third part that includes a regular expression that, upon evaluation, produces output including an indication of the resource. The system includes a processing system configured to evaluate an authorization request to the resource based on the three part permission structure.
In certain example embodiments, a computer implemented method of evaluating an authorization request in an authorization application is provided. The authorization request is made from a first computing application. The authorization request is received from the first computing application. A security context is created based on the authorization request. The security context includes information on: a requesting client; a resource associated with the request, and at least one permission associated with the resource. At least one rule is retrieved that is associated with a callback function that calls an authentication process that is defined in a second computing application. An abstract syntax tree is built based on the security context and the at least one rule. The abstract syntax tree is evaluated. A callback is performed to the authentication process defined in the second computing application during the evaluation of the abstract syntax tree. A result of the authorization request is returned based on the evaluation of the abstract syntax tree to the first computing application.
Non-transitory computer readable storage mediums tangibly storing instructions for performing the above-summarized and/or other methods also are provided by certain example embodiments, as well as corresponding computer programs.
Systems and/or computer based apparatus may also be configured or adapted to implement the above-summarized and/or other methods provided in certain example embodiments.
These features, aspects, advantages, and example embodiments may be used separately and/or applied in various combinations to achieve yet further embodiments of this invention.